home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 2461 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 21 Jan 1996 14:44:46 +0100
  6. Organization: dis-
  7. Message-ID: <4dtg0e$1j7@serpens.rhein.de>
  8. References: <DLAA61.2us@inter.NL.net> <4dh2dm$jui@serpens.rhein.de> <1292.6592T166T2158@algonet.se> <4do01q$fmc@serpens.rhein.de> <19960120.7B57BE0.122A3@asd01-04.dial.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. jtv@xs4all.nl (Jeroen T. Vermeulen) writes:
  12.  
  13. >I think it's because Forbid()/Permit() is still used in a lot of places where
  14. >the OS should have defined a separate semaphore (and probably implemented
  15. >deadlock detection and resolution as well).  So this memory is *more likely* to
  16. >page-fault during Forbid().
  17.  
  18. Actually the problem is that the flag MEMF_PUBLIC was never used for
  19. anything and wasn't thought out well.
  20.  
  21. >[1] implement a special driver for the swap device as a single-threaded library,
  22. >more or less like other OS's do (boo!), or
  23.  
  24. Which can't be single-threaded because the disk driver can use arbitrary
  25. tasks. That's no BIOS.
  26.  
  27. >[2] make a radical change:  Design around the problem for the new PPC OS so the
  28. >problem is limited to the 68k emulator (compatibility vs VM/MP--past vs future!)
  29.  
  30. The radical change is that software has to declare wether data has to
  31. be locked in memory and it has to declare who will get access to the
  32. data.
  33.  
  34. Of course there will be unprotected memory, heuristics for old programs
  35. (like the VMM database) and automatisms that let shared libraries handle
  36. private data without special preparations.
  37.  
  38. >The easiest change would perhaps be, to have multiple public-memory pools for
  39. >different groups of communicating processes,
  40.  
  41. Right.
  42.  
  43. >each guarded by a semaphore, and
  44. >change the meaning of the current Forbid() calls to "Obtain non-shared (write)
  45. >access to all virtual public memory spaces accessible to me".
  46.  
  47. This unfortunately does not work. But Forbid() isn't really useful
  48. either in most situations. New programs really must use other
  49. arbitration mechanisms. That's another reason why I want Forbid()
  50. and Disable() to be trapped. A multiprocessor configuration will
  51. then be the end of the "traditional" use of Forbid().
  52.  
  53.  
  54. -- 
  55.                                 Michael van Elst
  56.  
  57. Internet: mlelstv@serpens.rhein.de
  58.                                 "A potential Snark may lurk in every tree."
  59.